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Warnings 


■  Do  not  attempt  to  configure  any  of  the  recommendations  in  this  guide 
without  first  testing  in  a  non-operationai  environment. 

■  This  document  is  oniy  a  guide  containing  recommended  security  configurations. 
It  is  not  meant  to  repiace  weii -structured  poiicy  or  sound  judgment.  Furthermore 
this  guide  does  not  address  site-specific  configuration  issues.  Care  must  be 
taken  when  impiementing  this  guide  whiie  using  products  such  as  Microsoft 
Exchange,  IIS,  and  SMS. 

■  The  security  changes  described  in  this  document  oniy  appiy  to  Microsoft 
Windows  2000  systems  and  should  not  be  applied  to  any  other  Windows  2000 
or  Windows  NT  versions  or  operating  systems. 

■  You  can  severely  impair  or  disable  a  Windows  2000  system  with  incorrect 
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Configuration  Tool  Set,  Regedt32.exe,  and  Regedit.exe)  to  change  the 
system  configuration.  Therefore,  it  s  extremely  important  to  test  all  settings 
recommended  in  this  guide  before  installing  them  on  an  operational  network. 

■  Currently,  no  Undo  function  exists  for  deletions  made  within  the  Windows  2000 
registry.  The  registry  editor  (Regedt32  .exe  or  Regedit  .exe)  prompts  you  to 
confirm  the  deletions  if  Confirm  On  Delete  is  selected  from  the  options  menu. 
When  you  delete  a  registry  key,  the  message  does  not  include  the  name  of  the 
key  you  are  deleting.  Therefore,  check  your  selection  carefully  before 
proceeding  with  any  deletion. 

■  SOFTWARE  IS  PROVIDED  "AS  IS"  AND  ANY  EXPRESS  OR  IMPLIED 
WARRANTIES,  INCLUDING,  BUT  NOT  LIMITED  TO,  THE  IMPLIED 
WARRANTIES  OF  MERCHANTABILITY  AND  FITNESS  FOR  A  PARTICULAR 
PURPOSE  ARE  EXPRESSLY  DISCLAIMED.  IN  NO  EVENT  SHALL  THE 
CONTRIBUTORS  BE  LIABLE  FOR  ANY  DIRECT,  INDIRECT,  INCIDENTAL, 
SPECIAL,  EXEMPLARY,  OR  CONSEOUENTIAL  DAMAGES  (INCLUDING,  BUT 
NOT  LIMITED  TO,  PROCUREMENT  OF  SUBSTITUTE  GOODS  OR  SERVICES; 
LOSS  OF  USE,  DATA,  OR  PROFITS;  OR  BUSINESS  INTERRUPTION) 
HOWEVER  CAUSED  AND  ON  ANY  THEORY  OF  LIABILITY,  WHETHER  IN 
CONTRACT,  STRICT  LIABILITY,  OR  TORT  (INCLUDING  NEGLIGENCE  OR 
OTHERWISE)  ARISING  IN  ANY  WAY  OUT  OF  THE  USE  OF  THIS 
SOFTWARE,  EVEN  IF  ADVISED  OF  THE  POSSIBILITY  OF  SUCH  DAMAGE. 
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Introduction 

This  document  is  a  DRAFT  only  and  may  be  incomplete.  The  purpose  of  this 
document  is  to  provide  Active  Directory  security  configuration  guidance  and 
recommendations.  This  draft  is  meant  to  be  a  starting  point  for  Windows  2000 
Active  Directory  security  and  does  not  include  numerous  Windows  2000  functions 
and  applications  associated  with  Active  Directory.  This  document  is  a  companion  to 
the  “Guide  to  Securing  Microsoft  Windows  2000:  Security  Configuration  Tooi  Set”  and 
other  documents  that  comprise  the  overaii  NSA  Windows  2000  guidance. 

The  foiiowing  essentiai  assumptions  have  been  made  to  iimit  the  scope  of  this  document: 


■  The  network  consists  oniy  of  machines  running  Microsoft  Windows  2000  ciean- 
instaiied  machines  (i.e.  not  upgraded)  with  the  iatest  service  pack. 

■  Aii  network  machines  are  Intei-based  architecture. 

■  Appiications  are  Windows  2000  compatibie. 

■  Users  of  this  guide  have  instaiied  or  have  access  to  the  Windows  2000  toois  and 
utiiities  contained  in  the  Microsoft  Windows  2000  Server  Resource  Kit. 

■  Users  of  this  guide  have  a  working  knowiedge  of  Windows  2000  instaiiation  and 
basic  system  administration  skiiis. 

This  document  is  intended  for  Windows  2000  network  administrators,  but  shouid  be  read 
by  anyone  invoived  or  interested  in  Windows  2000  or  network  security. 


WARNING:  This  guide  does  not  address  security  issues  for 
the  Microsoft  Windows  2000  operating  system  that  are  not 
specificaiiy  reiated  to  the  Active  Directory  and  its 
implementation. 


Getting  the  Most  from  this  Guide 


The  foiiowing  iist  contains  suggestions  to  successfuiiy  secure  the  Windows  2000  Active 
Directory  according  to  this  guide: 


□ 


WARNiNG:  This  iist  does  not  address  site-specific  issues 
and  every  setting  in  this  book  shouid  be  tested  on  a  non- 
operationai  network. 


Read  the  guide  in  its  entirety.  Omitting  or  deieting  steps  can  potentiaiiy  iead  to 
an  unstabie  system  and/or  network  that  wiii  require  reconfiguration  and 
reinstaiiation  of  software. 


□  Perform  pre-configuration  recommendations: 

o  Perform  a  compiete  backup  of  your  system  before  impiementing  any  of 
the  recommendations  in  this  guide 

□  Foiiow  the  security  settings  that  are  appropriate  for  your  environment. 
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Commonly  Used  Names 


Throughout  this  guide  the  network  name  “test.gov”  and  the  subnet  192.168.0  may  be 
used  in  the  exampies,  screenshots,  and  iistings. 

WARNING:  It  Is  extremely  Important  to  replace  “test.gov”  and 
192.169.0  with  the  appropriate  network  name  and  subnet  for 
the  networks  being  secured.  These  names  are  not  real 
networks  and  have  been  used  for  demonstration  purposes 
only. 


About  the  Guide  to  Securing  Microsoft  Windows  2000:  Active  Directory 


This  document  consists  of  the  foiiowing  chapters: 

Chapter  1,  “Active  Directory  Overview,”  discusses  the  approach  of  the  Active 
Directory  Mini-guide  and  provides  some  topoiogy  considerations. 

Chapter  2,  “Domain  Name  System,”  provides  guidance  about  the  Domain  Name 
System  (DNS)  as  it  reiates  to  Active  Directory.  Information  about  Active  Directory  DNS 
security  functionaiity  and  requirements  is  provided;  bugs  and  incompatibiiities  are  pointed 
out. 

Chapter  3,  “Active  Directory  Instaiiation,”  expiains  Active  Directory  instaiiation 
requirements  and  security  issues. 

Chapter  4,  “Domains  and  Organizationai  Units,  ”  iiiustrates  the  security  properties  of  a 
domain  as  an  Active  Directory  container  object.  Active  Directory  object  access  controi  is 
expiained,  and  domain  controiier  physicai  security  and  vuinerabiiity  issues  are  discussed. 

Chapter  5,  “Trees  aid  Forests,”  expiains  how  muitipie  domains  can  be  configured 
using  Active  Directory  trusts. 

Chapter  6,  “Object  Access  Controi,”  discusses  Active  Directory  object  security. 

Chapter  7,  “Repiication,”  discusses  repiication  confiicts  that  can  occur  and  how  b 
minimize  confiicts.  Active  Directory  site  issues  are  expiored. 

Chapter  8,  “Operations  Masters,”  provides  piacement  guideiines  for  managing  the 
various  operations  masters  and  the  Giobai  Cataiog. 

Chapter  9,  “Auditing,”  teiis  how  to  audit  an  Active  Directory  container  or  ieaf  object  and 
how  to  view  and  manage  audit  output. 

Chapter  10,  “Backup/Restore  and  Database  Maintenance,”  discusses  security  issues 
reiated  to  backup/restore  and  restore  mode  password  protection. 

Append  A,  “References,”  contains  a  iist  of  resources  cited. 


Comments 


As  this  document  is  a  work  in  progress,  comments,  suggestions,  questions,  and  bug 
reports  are  weicome  and  encouraged.  Send  an  emaii  to 
W2KComments@dewnet.ncsc.mil  describing  the  issue  in  detail.  In  order  to  allow  ample 
time  to  research  problems,  email  is  preferred  to  phone  calls. 
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Active  Directoiy  Overview 

Active  Directory  is  the  directory  service  used  for  Windows  2000  domain  controiiers. 
According  to  Microsoft,  a  di rectory  \s  a  source  used  to  store  information  about  objects.  A 
directory  service  inciudes  both  the  information  source  and  the  services  making  the 
information  avaiiabie  to  users. 

In  its  simpiest  definition,  Active  Directory  is  a  hierarchicai  namespace  of  objects  that  is 
tightiy  integrated  with  the  Domain  Name  System  (DNS).  Active  Directory  hoids 
information  on  objects  stored  in  underiying  domains,  trees,  and  forests.  Active  Directory 
aiso  provides  mechanisms  for  safeguarding  directory  objects  from  unauthorized  access. 

Since  Active  Directory  hoids  the  important  pieces  of  information  for  a  Windows  2000 
network,  speciai  care  must  be  taken  to  protect  its  integrity  and  contents. 

The  Active  Directory  mini -guide  is  intended  to  highiight  Windows  2000  Active  Directory 
security  capabiiities  and  issues  and  provide  security  configuration  guidance  and 
recommendations  for  system  administrators.  The  reader  is  assumed  to  have  basic 
knowiedge  of  Windows  2000  configuration  and  the  roie  Active  Directory  piays  in  a 
Windows  2000  network.  This  is  a  companion  voiume  to  other  mini -guides  that  are  part  of 
the  overaii  NSA  Guide  to  Securing  Microsoft  Windows  2000.  Because  the  Guide  to 
Securing  Microsoft  Windows  2000  is  intended  to  provide  guidance  and  toois  to  improve 
the  security  configuration  of  Windows  2000  systems  in  a  “typicai”  operationai 
environment,  it  does  not  advocate  specific  design  or  integration  poiicies. 

The  approach  of  this  mini-guide  is  somewhat  different  than  the  approach  of  other  security 
guides.  Some  guides  provi  de  discrete  settings  that  impiement  a  predictabie  security 
configuration  outcome.  The  recommendations  provided  in  this  mini -guide  are  somewhat 
more  fiexibie  and  are  intended  to  inform  administrators  and  to  aid  decision-makers  in 
arriving  at  their  own  poiicy  impiementations. 
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Domain  Name  System  (DNS) 

Active  Directory  uses  the  Domain  Name  System  (DNS)  for  name  resoiution,  to  iocate 
services,  and  to  estabiish  the  domain  namespace  for  the  Active  Directory  hierarchy. 
DNS  affects  the  design  of  the  organizationai  iayout  inciuding  forests,  trees,  domains,  and 
sites.  For  this  reason,  DNS  shouid  be  the  first  concept  designed.  DNS  design  shouid  not 
be  taken  iightiy  because  Active  Directory  does  not  currentiy  aiiow  the  naming  convention 
to  be  changed  without  compieteiy  re-instaiiing  Active  Directory  for  aii  affected  domains. 

This  section  provides  guidance  on  the  Domain  Name  Service  (DNS)  as  it  reiates 
specificaiiy  to  Active  Directory.  Additionai  DNS  guidance  can  be  found  in  the  Guide  to 
Securing  Microsoft  Windows  2000  DNS  mini-guide. 

\  NOTE:  Active  Directory  requires  DNS  Service  Resource 
A  Record  (SRV  RR)  support  and  BIND  8.1 .2  or  higher. 


DNS  can  be  configured  via  the  DNS  Instaiiation  Wizard.  The  wizard  can  be  used  to 
perform  the  foiiowing  functions: 

■  Instaii  the  DNS  Server  Service 

■  Create  a  forward  iookup  zone 

■  Configure  the  zone  as  Active  Directory  Integrated 

■  Enabie  secure  dynamic  updates  for  the  zone 


Active  Directory  Integrated  Zones 


Active  Directory  integrated  zones  aiiow  access  controi  over  who  can  update  DNS  and 
provide  better  repiication  and  fauit  toierance  capabiiity.  Using  Active  Directory  integrated 
zones,  the  DNS  server  properties  interface  can  be  used  to  manage  Access  Controi  Lists 
(ACLs)  for  which  groups  and  users  can  access  and  modify  a  specified  zone  or  resource 
record. 
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Figure  1  DNS  Security  Tab 


The  DNS  server  properties  security  tab  can  be  used  to  iink  users  and  the  designated 
DNS  administrators  groups,  such  as  the  DnsAdmins  group  shown  in  Figure  1,  and  to 
configure  permissions.  Groups  and  users  can  then  be  piaced  into  a  designated 
Organizationai  Unit  (OU)  or  other  container  so  that  the  appropriate  Group  Poiicy  Object 
(GPO)  can  be  appiied  (see  aiso  the  Guide  to  Securing  Microsoft  Windows  2000  Group 
Poiicy  mini-guide). 

With  directory -integrated  storage,  dynamic  zone  updates  are  propagated  within  the  muiti- 
master  Active  Directory  repiication  scheme.  This  avoids  be  traditionai  DNS  master 
server  becoming  a  singie  point  of  faiiure.  Furthermore,  zones  are  repiicated  and 
synchronized  to  new  domain  controiiers  automaticaiiy  whenever  a  new  zone  is  added  to 
an  Active  Directory  domain. 


Active  Directory  DNS  Interface 


The  Active  Directory  DNS  interface  aiiows  administrators  to  specify  the  servers  aiiowed 
to  participate  in  zone  transfers.  The  DNS  interface  aiso  aiiows  iogging  and  monitoring  of 
certain  events.  Captured  DNS  audit  events  are  viewabie  from  the  “DNS  Server”  iog  in 
the  Event  Viewer. 

Enabiing  oniy  secure  DNS  updates  at  a  server  causes  aii  updates  to  the  particuiar  server 
to  be  encrypted  during  transmission  over  the  network.  Microsoft  has  pubiished  a  warning 
about  how  a  DHCP  server  can  compromise  secure  dynamic  updates. 

WARNING:  In  the  Windows  2000  on-line  help  for  Dynamic 
Update  Is  the  following  caution:  “For  Windows  2000,  the  use 
of  secure  dynamic  updates  can  be  compromised  by  running 
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a  DHCP  server  on  a  domain  controller  when  Windows  2000 
DHCP  server  is  configured  to  perform  registration  of  DNS 
records  on  behalf  of  its  clients.  To  avoid  this  issue,  deploy 
DHCP  servers  and  domain  controllers  on  separate 
computers.  If  you  are  not  concerned  about  security  of 
reverse  lookup  (PTR)  records,  this  precaution  is  only 
advisable  if  the  DHCP  server  is  configured  to  perform 
registration  of  host  (A)  records  on  behalf  of  its  clients  (which 
is  not  a  default  behavior).” 


Static  Service  Locations 


Instead  of  using  dynamic  service  iocation,  Active  Directory  uses  static  service  iocations. 
This  ieads  to  a  probiem  where  service  records  remain  in  DNS  after  a  service  has  been 
removed  or  otherwise  become  unavaiiabie  -  servers  and  ciients  wiii  continue  to  beiieve 
that  the  service  is  stiii  avaiiabie. 

To  address  this  probiem,  Microsoft  provides  a  proprietary  server  aging/scavenging 
soiution  that  makes  use  of  a  previousiy  unused  DNS  extension.  The  aging/scavenging 
functionaiity  aiiows  Active  Directory  DNS  servers  to  age  out  and  remove  oid  DNS  service 
records.  The  defauit  time  is  seven  ckys.  One  probiem  with  this  is  that  services  wiii 
appear  avaiiabie  to  servers  and  ciients  untii  they  have  been  scavenged  (this  probiem 
may  aiso  affect  iocating  new  services).  Another  probiem  is  that  non-Windows  2000  DNS 
servers  do  not  have  the  abiiity  to  age  or  scavenge  oid  service  records.  This  issue  must 
be  considered  when  deciding  if  or  how  to  impiement  DNS  in  a  non-Windows  2000  DNS 
server  or  mixed  DNS  server  environment. 


Chapter  Security  Summary 


Recommendations 


□  Impiement  Active  Directory  integrated  zones. 

□  Use  or  create  Active  Directory  DNS  administrators  groups  and  users  to  manage 
DNS. 

□  Link  oniy  the  designated  DNS  administrators  groups  and  users  and  configure 
permissions  through  the  DNS  server  properties  security  tab. 

□  Piace  the  DNS  administrators  groups  and  users  into  a  designated  Organizationai 
Unit  (OU)  and  appiy  the  appropriate  Group  Poiicy. 

□  See  aiso  the  Guide  to  Securing  Windows  2000  DNS  mini-guide. 


Good  Practices 

□  Configure  support  for  dynamic  updates  and  incrementai  zone  transfers. 

□  Enabie  secure  dynamic  updates  for  the  zone. 

□  Routineiy  check  currency  of  service  records  and  manuaiiy  scavenge  as  needed. 

□  Make  use  of  the  Windows  2000  DNS  instaiiation  wizard  when  creating  zones. 
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□  Become  familiar  with  and  test  issues  regarding  interoperating  with  non-Windows 
2000  DNS  servers,  such  as  SRV  RR  support,  service  record  aging  and 
scavenging,  and  version  stability. 

□  Create  an  enterprise  DNS  audit  policy;  use  Active  Directory  DNS  interface  to  log 
and  monitor  DNS  events. 

□  Use  more  than  one  DNS  server  to  host  each  zone,  for  fault  tolerance. 

□  DNS  servers  should  be  local,  not  across  a  site  connection  (i.e.,  not  across  a 
WAN  or  slow-speed  link). 
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Active  Directoiy  Installation 

After  installing  a  Windows  2000  server  product  (server,  advanced  server,  or  data  center), 
the  server  can  be  promoted  to  a  domain  controller  by  installing  Active  Directory.  Active 
Directory  is  installed  using  the  Active  Directory  Installation  Wizard.  This  wizard  is 
launched  by  running  dcpromo.exe  from  the  command  prompt  or  by  running  Configure 
Your  Server  on  the  Administrative  Tools  menu  of  the  Start  menu.  The  Active  Directory 
Wizard  can  perform  the  following  functions: 


■  Add  a  domain  controller  to  an  existing  domain 

■  Create  the  first  domain  controller  of  a  new  domain 

■  Create  a  new  child  domain 

■  Create  a  new  domain  tree 

■  Install  a  DNS  server  with  a  default  configuration 

■  Create  the  database  and  database  log  files 

■  Create  the  shared  system  volume 

■  Remove  Active  Directory  services  from  a  domain  controller 

It  is  recommended  that  Active  Directory  domain.  Organization  Unit  (OU),  and  site 
topologies  be  carefully  considered  before  Active  Directory  installation.  It  is  also 
recommended  that  DNS  services  be  installed  and  configured  prior  to  Active  Directory 
installation  unless  the  default  Active  Directory  Installation  Wizard  DNS  configuration  is 
acceptable.  For  further  guidance,  see  also  the  Guide  to  Securing  Microsoft  Windows 
2000  DNS  mini-guide  and  the  DNS  section  of  this  mini-guide. 


Active  Directory  Defauit  Permissions 


During  Active  Directory  installation,  a  dialog  box  prompts  for  one  of  the  following  two 
permission  preferences  (see  Figure  2): 
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Figure  2  Active  Directory  Defauit  Permissions 


•  Permissions  compatibie  with  pre-Windows  2000  servers 

•  Permissions  compatibie  oniy  with  Windows  2000  servers 

Permissions  shouid  be  set  to  be  compatibie  oniy  with  Windows  2000  servers,  if  possibie. 
Permissions  compatibie  with  pre-Windows  2000  servers  aiiows  anonymous  users  read 
access  to  information  on  the  domain. 

No  matter  which  option  is  seiected,  the  buiit-in  Pre-Windows  2000  Compatibie  Access 
group  is  added  in  the  access  controi  iists  (ACLs)  and  user  rights  throughout  Active 
Directory  and  the  domain  controiier.  However,  with  the  first  option,  permissions 
compatibie  with  pre-Windows  2000-based  servers  are  seiected,  and  the  Everyone  group 
is  nested  in  the  Pre-Windows  2000  Compatibie  Access  group,  which  aiiows  anonymous 
connections  to  the  server.  With  the  second  option,  the  Everyone  group  is  not  nested. 

To  iater  change  this  permission  setting  to  be  compatibie  with  pre-Windows  2000  or  oniy 
with  Windows  2000  servers,  the  Everyone  group  can  be  added  or  deieted  from  the  Pre- 


Windows  2000  Compatibiiity  Access  group.  The  foiiowing 
deiete  the  Everyone  group: 

run  commands  wiii  add  or 

■  net  localgroup 

everyone  /add 

"Pre-Windows 

2000 

Compatible  Access" 

■  net  localgroup 

everyone  /delete 

"Pre-Windows 

2000 

Compatible  Access" 

If  pre-Windows  compatibie  access  is  needed  for  a  mixed-mode  Windows  2000/NT 
environment,  steps  shouid  be  taken  to  reduce  exposure  to  Everyone  group  access.  See 
aiso  the  Guide  to  Securing  Microsoft  Windows  2000  Group  Poiicy:  Security  Configuration 
Too/sef  mini-guide  for  more  information  on  iimiting  permissions  of  the  Everyone  group. 
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Directory  Services  Restore  Mode 


During  Active  Directory  instaiiation,  a  vaiue  for  the  Directory  Services  Restore  Mode 
Administrator’s  password  is  suppiied.  The  Directory  Services  Restore  Mode 
Administrator’s  password  is  used  to  restore  the  Active  Directory  database  from  a  backup 
and  to  protect  access  to  the  Active  Directory  database  fiie  ^tds.dit)  stored  on  the 
server.  Therefore,  it  is  important  to  protect  this  password.  The  restore  mode  password, 
uniike  typicai  Windows  2000  group  and  user  passwords,  is  stored  in  the  server’s  iocai 
Security  Accounts  Manager  (SAM)  data  store.  Therefore,  good  password  management 
guideiines  shouid  be  used  to  reduce  the  effectiveness  of  password-cracking  utiiities 
against  this  password.  SYSKEY  can  be  used  to  provide  additionai  protection  of  the 
SAMs  of  aii  domain  controiiers.  SYSKEY  is  discussed  in  greater  detaii  iater  in  this  guide. 


Chapter  Security  Summary 


Recommendations 

□  Set  permissions  compatibie  oniy  with  Windows  2000  servers,  if  possibie  (i.e.,  if 
not  in  mixed-mode). 

□  Use  robust  password  guideiines  (e.g.,  iength,  compiexity)  when  setting  the 
Directory  Services  Restore  Mode  Administrator’s  password.  Consider  using 
SYSKEY  for  additionai  security. 

Good  Practices 

□  Carefuiiy  consider  Active  Directory  topoiogies  before  instaiiing  Active  Directory. 

□  DNS  services  shouid  be  instaiied  and  configured  prior  to  Active  Directory 
instaiiation,  uniess  the  defauit  configuration  is  acceptabie. 
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Domains  and  Organizational  Units 

As  stated  earlier,  Active  Directory  is  a  hierarchical  structure.  Domains  are  the 
fundamental  container  objects  in  Active  Directory.  Within  domains,  Organizational  Units 
(OUs)  are  created  to  further  organize  objects. 

This  chapter  discusses  the  security  concerns  specifically  related  to  domains  and  OUs. 


Domain  Basics 


Windows  2000  domains  maintain  backward  compatibility  with  Windows  NT  domains  and 
must  match  DNS  names.  Active  Directory  domains  represent  a  security  boundary  or 
partition  because  permissions  and  authority  do  not  flow  in  or  out  of  a  domain. 
Permissions  can,  however,  flow  in  and  out  of  sites  and  Organizational  Units  (sites  are 
discussed  in  the  Replication  section). 


Figure  3  Domain  and  OU  Structure 


An  OU  is  typically  created  within  the  domain  to  further  organize  and  contains  individual 
resource  objects  (leaf  objects)  such  as  users,  computers,  and  shared  folders.  OUs  are 
illustrated  as  “directory  folder”  objects  within  a  domain  triangle  in  Figure  3.  OUs  are  the 
primary  container  object  used  to  delegate  authority  and  to  link  Group  Policy  Objects 
(GPOs).  The  other  container  objects  used  to  delegate  authority  and  link  to  GPOs  are 
domains  and  sites. 

When  creating  a  new  child  domain,  the  Active  Directory  Installation  Wizard: 

■  Creates  a  new  domain 
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■  Promotes  the  computer  to  a  new  domain  controller 

■  Establishes  a  transitive,  two-way  trust  relationship  with  the  parent  domain 

■  Replicates  schema  and  configuration  directory  partitions 


Domain  Administrators 


Within  the  domain,  domain  administrators  (members  of  the  Domain  Admins  group  and 
the  built-in  Administrator  account)  not  only  have  full  control  by  default,  they  also  have  the 
right  to  take  ownership  of  any  object  in  the  domain.  Using  this  right,  domain 
administrators  can  gain  full  control  over  any  object  in  the  domain,  regardless  of  the 
permissions  that  have  been  set  on  that  object.  Specifically,  there  is  no  way  to  prevent  a 
domain  admin  or  administrator  from  being  able  to  take  ownership  (control)  of  an  OU 
anywhere  in  the  domain.  The  Active  Directory  interface  indicates  that  blocking  or 
denying  permissions  is  effective  in  blocking  out  any  group  or  user  including  domain 
administrators,  which  is  misleading. 

Because  domain  administrators  have  full  control  throughout  the  domain,  membership  of 
the  domains  administrators  group  should  be  kept  small  and  controlled.  Also,  members  of 
the  domain  administrators  group  should  not  be  placed  in  OUs  to  manage  sub-domain 
elements  of  the  directory  tree.  One  approach  for  delegating  administration  within  a 
domain  is  as  follows: 

■  Create  an  OU  for  each  logical  subdivision  of  the  domain 

■  Create  a  local  group  for  each  subdivision  representing  the  highest  level 
administration  in  that  subdivision 

■  Assign  the  given  group  full  control  over  its  OU 

■  If  the  subdivision  is  allowed  to  set  their  membership,  place  the  subdivision's 
administrators  group  into  the  OU.  Otherwise,  leave  the  group  outside  the  OU. 


Group  Policy  Objects 


When  an  object  is  created  in  the  directory,  a  default  access  control  list  (ACL)  is  applied. 
The  default  ACL  is  described  in  the  schema  definition  of  the  object  class.  Beyond  these 
default  permissions,  security  management  for  Active  Directory  user  and  computer  objects 
is  brgely  performed  with  Group  Policy  Objects  (GPOs)  that  are  linked  (applied)  to 
domain,  OU  and  site  container  objects.  Additional  Group  Policy  guidance  can  be  found 
in  the  Guide  to  Securing  Microsoft  Windows  2000  Group  Po//cy  mini -guide. 

By  default,  GPOs  are  inherited.  Inheritance  flows  from  site  to  domain  to  OU.  Child  OUs, 
for  example,  inherit  GPOs  from  parent  OUs.  There  is  no  GPO  inheritance  hierarchy  for 
domains  as  there  is  for  OUs,  such  as  from  parent  OU  to  child  OU  and  so  forth.  Figure  4 
illustrates  GPO  inheritance. 
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Default  Users  and  Computers 


When  Active  Directory  is  instaiied  on  the  first  domain  controiier  in  a  new  domain,  severai 
defauit  objects  are  created.  These  objects  inciude  Buiitin,  Computers,  and  Users  foiders. 
Because  effective  Active  Directory  management  depends  on  impiementing  an  OU 
structure  within  a  domain  for  deiegation  of  administrative  controi  and  Group  Poiicy,  the 
defauit  users  and  computers  foiders  shouid  oniy  be  used,  if  needed,  to  initiaiiy  pian  and 
create  a  manageabie  OU  structure.  As  soon  as  possibie,  user  and  computer  objects 
shouid  be  reiocated  to  OUs  within  the  target  structure. 


Hiding  Active  Directory  Objects  in  OUs 


OUs  can  be  created  to  hide  objects.  Biocking  the  “List  Contents”  permission  for  an  OU 
makes  the  OU  and  its  contents  invisibie  to  affected  users.  Oniy  users  who  can  modify 
the  access  controi  iist  (ACL)  on  an  OU  can  hide  objects  in  this  way.  This  feature  can  be 
used  to  compartment  the  iogicai  structure  of  the  directory  to  meet  management  poiicies 
and  objectives.  On  the  negative  side,  this  feature  aiso  couid  be  used  to  “backdoor”  a 
system,  i.e.,  to  create  a  priviieged  user  and  piace  that  user  into  a  hidden  OU  container. 

When  an  administrator  attempts  to  view  a  hidden  OU,  the  OU  object  wiii  appear  as  an 
object  without  an  icon.  When  the  object’s  security  tab  is  seiected,  the  security 
information  wiii  be  unavaiiabie.  These  are  the  indications  to  administrators  that  an  OU 
has  been  created  to  hide  Active  Directory  objects.  If  such  activity  is  suspicious,  the 
administrator  can  perform  the  foiiowing  steps  to  regain  controi  of  the  hidden  object: 

■  Open  another  object  to  which  the  administrator  has  priviiege 

■  View  the  security  settings  of  the  other  object 

■  Return  to  view  the  security  tab  of  the  hidden  object 

■  The  security  settings  wiii  now  be  visibie  and  can  be  managed  by  the  administrator 
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■  The  administrator  can  now  grant  other  objects  rights  to  this  OU 

■  The  administrator  can  now  reset  inherited  permissions 

The  steps  to  find  and  take  controi  of  hidden  OU  objects  must  be  done  manuaiiy. 


Domain  Controller  Security 


Domain  controiiers  contain  sensitive  information,  such  as  copies  of  users’  secret  keys 
used  for  domain  authentication.  Therefore,  the  security  of  domain  controiiers  shouid  be  a 
high  priority. 

Physical  Security 

Having  fewer  copies  of  domain  controiier  information  physicaiiy  accessibie  to 
unsupervised  persons  reduces  the  risk  for  unauthorized  access.  Domain  controiiers 
must  be  kept  physicaiiy  secure  from  unauthorized  access.  For  exampie,  it  is 
recommended  that  domain  controiiers  be  iocated  in  a  iocked  room  with  iimited  access. 
Physicai  access  can  aiiow  an  intruder  to  obtain  copies  of  encrypted  password  data  to  use 
for  an  off-iine  password  attack. 

SYSKEY  Concerns 

The  use  of  SYSKEY  introduces  additionai  security  and  ease  of  use  issues,  as  described 
by  Microsoft  in  http://support.microsoft.eom/support/kb/articies/q143/4/75.asp.  For 
exampie,  SYSKEY  uses  its  own  key  that  must  aiso  be  protected.  Because  the  SYSKEY 
binary  key  is  needed  to  boot  a  domain  controiier  (computer),  if  a  fioppy  disk  containing 
the  binary  key  were  stored  insecureiy  near  the  target  machine,  for  exampie,  it  couid  be 
used  to  bypass  SYSKEY.  Unattended  system  restart  couid  require  that  the  SYSKEY 
materiai  be  stored  on  the  iocai  hard  drive  so  that  the  system  can  be  restarted  without 
Administrator  response,  thus  reducing  the  ievei  of  security.  If  the  SYSKEY  password  is 
forgotten  or  the  removabie  media  is  iost,  it  may  not  be  possibie  to  start  the  system.  Aiso, 
SYSKEY  couid  affect  repair  options  for  system  recovery.  Figure  5  shows  the  options  for 
the  storage  of  SYSKEY  startup  keys. 
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Figure  5  SYSKEY  Password  Storage 


Fault  Tolerance 

Immediately  after  Active  Directory  is  installed  on  the  first  domain  controller,  at  least  one 
additional  domain  controller  should  be  installed  to  prevent  loss  of  the  database  if  the  first 
server  crashes. 


Chapter  Security  Summary 


Recommendations 


□  Create  separate  domains  as  needed  to  partition  or  compartment  portions  of 
Active  Directory  requiring  different  security  or  administrative  policies. 

□  Physically  secure  domain  controllers. 

□  As  soon  as  possible,  move  default  user  and  computer  objects  into  OUs  within  the 
target  OU  structure. 


Good  Practices 

□  Membership  of  the  domain  administrators  group  should  be  kept  small  and 
controlled. 

□  Members  of  the  domain  administrators  group  generally  should  not  be  placed  in 
OUs  to  manage  sub-domain  elements  of  the  directory  tree. 

□  Take  steps  to  ensure  that  unauthorized  hidden  OU  objects  do  not  exist  within  the 
directory  structure. 
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□  Use  SYSKEY  to  augment  the  physical  protection  of  domain  controllers. 

□  At  least  one  sub-domain  or  replica  domain  controller  should  be  installed  shortly 
after  the  first  domain  controller  is  installed  to  prevent  loss  of  the  database  if  the 
first  server  crashes. 


UNCLASSIFIED 


19 


Domains  and  Organizational 
Units 


Trees  and  Forests 


UNCLASSIFIED 


Chapter 

5 


Trees  and  Forests 

A  tree  is  a  collection  of  domains,  connected  by  trust  relationships,  which  share  a 
contiguous  DNS  namespace.  A  forest  is  a  collection  of  domains,  connected  by  trust 
relationships,  whose  DNS  namespace  is  not  contiguous.  All  domains  in  trees  or  forests 
have  the  following  in  common: 

■  Global  Catalog  -  Holds  a  copy  (replica)  of  every  object  in  Active  Directory,  but  with  a 
limited  number  of  each  object’s  attributes.  The  Global  Catalog  stores  those  attributes 
most  frequently  used  in  search  operations  and  user  logon,  and  attributes  required  to 
locate  a  full  replica  of  the  object. 

■  Schema  -  Defines  the  classes  and  attributes  of  objects  that  can  be  created  in  the 
Active  Directory  database. 

■  Configuration  -  A  naming  context  that  is  replicated  to  every  domain  controller  in  the 
forest.  The  Configuration  holds  and  uses  site  information  to  make  connections. 


Design  Considerations 


In  Active  Directory,  the  first  domain  created  is  the  root  domain  controller,  tree  root 
domain,  and  forest  root  domain,  even  though  there  is  only  one  domain.  The  first  domain 
controller  stores  the  Global  Catalog,  Schema  and  Configuration.  As  the  forest  root 
domain,  the  two  predefined  security  groups  created  to  manage  forests  are: 

■  Enterprise  Admins  -  A  universal  group  if  the  domain  is  in  native  mode,  a  global 
group  if  the  domain  is  in  mixed  mode.  This  group  is  authorized  to  make  changes  to 
the  entire  forest  in  Active  Directory,  such  as  adding  child  domains. 

■  Schema  Admins  -  A  universal  group  if  the  domain  is  in  native  mode,  a  global  group 

if  the  domain  is  in  mixed  mode.  This  group  is  authorized  to  make  schema  changes  in 
Active  Directory. 

In  Active  Directory,  DNS,  tree,  and  forest  implementation  hinges  on  the  first  domain 
created.  Subdomains  and  Active  Directory  trees  that  will  be  included  in  a  forest  must  be 
linked  with  the  first  domain  as  their  Active  Directory  configurations  are  installed.  An 
established  domain  or  tree  cannot  later  join  a  forest.  Although  non-transitive  trust 
relationships  can  be  provided  to  established  domains,  trees  and  forests,  the  preferred 
Active  Directory  two-way,  transitive  trust  relationship  is  not  available  to  domains  and 
trees  that  were  not  installed  into  the  forest  root  domain. 

Active  Directory  is  a  new  technology  and  does  not  yet  provide  tools  or  methods  to 
change  or  add  flexibility  to  tree  and  forest  design.  Most  tree  and  forest  implementations 
are  permanent  and  cannot  be  changed  or  undone  without  reinstalling  domain  controllers 
or  entire  trees.  Significant  planning  must  be  done  before  creating  the  DNS  namespace, 
trees,  and  forests. 

After  the  first  domain  is  created,  subsequent  Active  Directory  installations  within  a  forest 
can  accomplish  the  following: 
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■  Create  a  replica  within  a  domain 

■  Create  a  subdomain  that  extends  the  namespace 

■  Create  a  subdomain  with  a  non-contiguous  namespace 

When  subsequent  domain  controllers  are  installed,  Active  Directory  will  begin  to 
exchange  copies  or  replicas  of  the  Global  Catalog,  Schema,  and  Configuration  among 
the  domain  controllers.  Within  a  domain,  large  portions  of  these  databases  are 
exchanged.  Between  domains  only  the  changes  or  updates  are  exchanged. 

Advantages  of  a  Single  Domain  Architecture 

The  primary  advantage  of  having  a  single  domain  for  the  entire  system  or  enterprise  is  to 
simplify  system  management.  The  security  benefits  of  a  single  domain  system  include 
the  following: 

■  It  is  easier  to  manage  and  trace  Active  Directory  object  access  control  and  Group 
Policy  inheritance  since  permissions  are  contained  within  the  domain  boundary. 

■  Domain  administrators  have  complete  control  over  the  entire  system  because  they 
cannot  be  blocked  out  of  containers. 

Advantages  of  a  Multiple  Domain  Architecture 

Some  general  and  security-related  benefits  of  having  multiple  domains  in  the  system  or 
enterprise  include  the  following: 

■  Multiple  domains  can  reduce  replication  traffic  since  replication  between  domains 
only  involves  changes  to  the  Active  Directory  database 

■  It  might  be  easier  to  implement  distinct  security  settings  by  using  separate  domains 

■  Multiple  domains  might  aid  in  the  transition  from  Windows  NT  domains  to  Windows 
2000  domains 

■  Separate  domains  may  be  required  to  block  administrative  authority  from  one  part  of 
a  system  to  another 


Active  Directory  Trusts 


As  each  new  domain  controller  is  installed  into  a  forest.  Active  Directory  automatically 
and  transparently  creates  a  two-way,  transitive  trust  between  the  forest  root  or  the  parent 
domain  and  the  new  domain.  Because  the  trust  is  two-way,  the  trust  paths  between  the 
domains  extend  in  both  directions.  Because  the  trust  is  transitive,  the  trust  relationship  is 
extended  to  all  domains  that  are  connected  together  with  a  transitive  trust.  Transitive 
trusts  can  be  distinguished  as  either  parent-child  trusts,  or  as  trusts  between  tree  roots. 
Figure  6  shows  trust  relationships  within  a  forest. 
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Figure  6  Forest  Trust  Relationships 


Kerberos  V5  verifies  trust  reiationships  in  Active  Directory.  When  a  user  in  a  trusted 
domain  tries  to  access  a  resource  in  another  domain,  the  user’s  computer  contacts  the 
domain  controiier  in  its  iocai  domain  to  get  authentication  to  the  resource.  If  the  resource 
is  not  in  the  user’s  domain,  the  iocai  domain  controiier  uses  the  trust  reiationship  with  its 
parent  to  refer  the  requesting  computer  to  the  parent  domain  controiier.  This  chain  of 
requests  continues  through  the  trust  hierarchy  untii  the  request  reaches  the  domain  in 
which  the  resource  resides.  Kerberos  is  further  described  in  the  Kerberos  mini-guide. 

Within  a  forest,  a  shortcut  trust  can  be  created  to  reduce  the  iength  of  the  trust  hierarchy 
between  network  resources. 

Noi>4ransitive  Trusts 

A  non-transitive,  or  one-way,  trust  can  be  created  between  Active  Directory  domains 
where  a  transitive  trust  reiationship  does  not  or  cannot  exist.  Care  must  be  taken  when 
expiicitiy  estabiishing  a  one-way  trust.  Oniy  necessary  trusts  shouid  be  created. 

Non-transitive  trusts  can  be  used  in  the  foiiowing  situations: 

■  Between  a  Windows  2000  domain  and  a  Windows  NT  domain. 

■  Between  a  Windows  2000  domain  in  one  forest  and  a  Windows  2000  domain  in 
another  forest. 

■  Between  a  Windows  2000  domain  and  a  Kerberos  V5  protocoi  security  reaim. 


Non-transitive  trusts  are  manuaiiy  created  and  are  one-way,  aithough  a  one-way  non¬ 
transitive  trust  can  be  created  for  both  directions  to  accompiish  a  two-way  non-transitive 
trust  reiationship. 

Trusts  can  be  viewed,  verified,  or  removed  in  Active  Directory  Domains  and  Trusts  as 
foiiows: 

■  Seiect  Start  ?  Programs  ?  Administrative  Tools  ?  Active  Directory  Domains  and 
Trusts 
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■  Right-click  a  domain  and  click  Properties.  The  domains  trusted  by  this  domain  and 
the  domains  that  trust  this  domain  are  visible 

To  verify  a  trust  relationship: 

■  From  the  Trusts  tab,  select  a  domain  to  verify  and  click  Edit 

■  Click  Verify /Reset 
To  remove  a  trust: 

■  From  the  Trusts  tab,  select  a  domain  to  remove  and  click  Remove 

Trusts  Between  Multiple  Forests 

It  is  possible  to  link  multiple  forests  together  with  non-transitive  trust  relationships. 
Linking  multiple  forests  may  be  necessary  due  to  any  number  of  circumstances  such  as 
organizations  or  companies  merging  together  or  operational  needs  to  merge  systems  that 
were  previously  separate.  While  there  is  yet  no  graceful  forest  merge  capability  with 
Active  Directory,  system  decision-makers  are  basically  faced  with  the  following  choices: 


■  Maintain  separate  forests 

■  Manually  recreate  and  copy  objects  from  one  forest  to  another 

Some  of  the  consequences  of  having  multiple  forests  include  the  following: 

■  There  will  be  multiple  schemas.  Maintaining  consistency  between  them  will  create 
overhead  and  be  difficult. 

■  There  will  be  multiple  Configuration  containers.  Network  topology  changes  will  have 
to  be  replicated  to  each  affected  forest,  and  maintaining  consistency  will  create 
overhead. 

■  Explicit  trusts  between  individual  domains  will  need  to  be  established  and 
maintained.  There  are  no  transitive  trusts  between  forests,  so  multiple  domains 
requiring  inter-forest  trust  relationships  will  require  a  mesh  of  one-way  explicit  trusts. 

■  Users  will  need  to  make  explicit  queries  for  resources  outside  their  forest. 

■  Any  replication  of  information  between  forests  will  be  manual  and  will  require  an 
administrative  process  for  keeping  such  information  up-to-date. 

■  Users  logging  on  to  computers  in  forests  outside  their  own  must  use  the  default  (full 
domain  path)  UPN  when  logging  on. 

■  Accounts  cannot  be  easily  moved  between  forests.  Account  moves  between  forests 
must  use  cloning  or  a  bulk  import  utility. 

NOTE:  When  user  accounts  are  bulk  imported,  the  pre-import 
account  password  cannot  be  preserved.  It  is  possible  to 
specify  a  new  password  during  the  bulk  import,  but 
managing  unique  passwords  for  a  large  number  of  imported 
accounts  is  probably  somewhat  unwieldy,  thus  it  would  be 
tempting  to  use  generic  passwords.  Also,  the  new 
passwords  must  somehow  be  distributed  to  affected  users, 
which  presents  an  additional  potential  security  problem. 

Therefore,  it  is  recommended  that  bulk  imported  accounts  be 
imported  as  inactive.  Users  can  later  create  or  change  their 
passwords  as  their  accounts  are  activated. 
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Chapter  Security  Summary 


Recommendations 

□  Significant  pianning  must  be  done  before  creating  the  DNS  namespace,  trees, 
and  forests  because  many  aspects  of  these  structures  cannot  be  iater  modified. 

□  Maintain  separate  domains  as  needed  to  biock  administrative  authority  from  one 
part  of  a  system  to  another. 

□  Buik  imported  accounts  shouid  be  inactive;  a  secure  method  to  create  or  change 
the  account  password  as  each  account  is  activated  shouid  be  iocaiiy  devised. 

Good  Practices 


□  Avoid  the  use  of  muitipie  forests. 

□  Create  shortcut  trusts  between  frequentiy  accessed  domains  with  iong  trust 
paths. 

□  Use  separate  domains  to  impiement  distinct  security  settings. 
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Object  Access  Control 

Like  file  permissions  in  NTFS,  the  security  of  Active  Directory  objects  is  based  on  access 
control  lists  (ACLs).  This  chapter  discusses  the  basics  behind  Active  Directory  object 
ACLs  and  strategies  for  managing  these  ACLs. 

The  Active  Directory  security  components  are  as  follows: 

■  Security  Principals  -  User,  security  group,  service,  and  computer;  Identified  by  a 
unique  ID 

■  Security  Identifiers  (SIDs)  -  Uniquely  identify  security  principals;  Are  never  reused 

■  Security  Descriptors  -  Security  information  associated  with  an  object;  Contains 
Discretionary  Access  Control  Lists  (DACLs)  and  System  Access  Control  Lists 
(SACLs) 

Access  control  for  Active  Directory  services  works  through  security  descriptors 
associated  with  every  directory  object  or  property.  Each  security  descriptor  contains  a 
discretionary  access  control  list  (DACL)  and  a  system  access  control  list  (SACL).  The 
DACL  is  a  set  of  access  control  entries  (ACEs),  each  having  a  security  identifier  (SID) 
that  represents  the  security  principal  (user,  group,  or  computer)  to  whom  the  ACE 
applies,  and  permissions,  which  allow  or  deny  users  and  groups  rights  to  the  objects.  An 
ACE  is  used  to  determine  which  accesses  a  security  principal  is  allowed  to  an  object,  or 
for  a  SACL,  which  accesses  are  audited.  An  example  of  a  permission  attached  to  an 
object  is  Read  permission  on  a  container  attribute.  The  DACL  determines  who  can  see 
the  object  and  what  actions  can  be  performed. 

If  auditing  is  configured  for  the  object,  its  security  descriptor  also  contains  a  system 
access  control  list  (SACL)  that  controls  how  the  security  subsystem  audits  attempt  to 
access  the  object. 

Inheritance 

Through  inheritance,  the  ACEs  in  a  parent  object’s  security  descriptor  are  passed  to  a 
child  object’s  descriptor.  ACE  inheritance  propagation  from  parent  to  child  object 
happens  when  a  child  object  is  created  or  when  a  DACL  or  SACL  on  the  parent  object  is 
modified.  To  prevent  child  objects  from  inheriting  permissions,  uncheck  the  Allow 
inheritable  permissions  from  parent  to  propagate  to  this  object  check  box.  When 
permissions  are  blocked,  the  administrator  is  asked  to  choose  whether  to  copy  the 
previously  inherited  permissions  to  the  object,  or  remove  them. 

Modifying  Object  Permissions 

To  view,  add  or  change  permissions  or  to  block  inheritance  to  child  objects,  perform  the 
following  steps: 
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□  Click  Start  ?  Programs  ?  Administrative  Tools  ?  Active  Directory  Users  and 
Computers 

□  On  the  Viewmenu,  click  Advanced  Features 

□  Right-click  the  object  and  select  Properties 

□  In  the  Properties  dialog  box,  click  the  Security  tab 
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Figure  7  Object  Security  Properties 


An  example  of  an  object’s  security  properties  is  shown  in  Figure  7. 

Active  Directory  permissions  can  be  allowed  or  denied.  When  permission  to  perform  an 
action  is  not  explicitly  assigned,  it  is  implicitly  denied.  Permissions  can  also  be  explicitly 
denied.  Object  permissions  can  be  set  as  standard  or  special.  Special  permissions 
provide  a  finer  degree  of  control  for  assigning  access  to  objects. 


Active  Directory  Groups 


In  Active  Directory  there  are  two  group  types: 

■  Security  Groups  -  used  with  access  controls 

■  Distribution  Groups  -  used  with  email  (Exchange)  applications 

Security  groups  are  listed  in  DACLs  that  define  permissions  on  resources  and  objects. 
Distribution  groups  are  not  security-enabled.  They  cannot  be  listed  in  DACLs,  but  are 
used  only  with  email  applications,  such  as  Exchange,  to  send  email  to  a  group  of 
individuals.  Distribution  groups  should  never  be  used  to  create  a  general-purpose  group 
and  should  be  avoided. 

The  following  Active  Directory  security  group  scopes  are  available: 


UNCLASSIFIED 


27 


Object  Access  Control 


Object  Access  Control 


UNCLASSIFIED 


■  Universal 

■  Global 

■  Domain  Local 

Universal  groups  are  available  only  in  native  mode.  Universal  groups  are  useful  to 
consolidate  groups  that  span  multiple  domains,  but  can  cause  replication  overhead  (see 
the  Replication  chapter  in  this  guide).  When  processing  a  logon  request  for  a  user  in  a 
native-mode  domain,  a  domain  controller  sends  a  query  to  a  global  catalog  server  to 
determine  the  user’s  universal  group  memberships.  Since  groups  can  be  explicitly 
denied  access  to  a  resource,  complete  knowledge  of  a  user’s  group  memberships  is 
necessary  to  enforce  access  control  correctly.  If  a  domain  controller  of  a  native -mode 
domain  cannot  contact  a  global  catalog  server  when  a  user  tries  to  log  on,  the  domain 
controller  refuses  the  logon  request.  In  a  single  domain  environment,  global  catalog 
servers  are  not  required  to  process  a  user  logon  request. 

Microsoft  recommends  the  following  group  nesting  strategy: 


■  Place  domain  users  into  Global  Groups. 

■  Nest  Global  Groups  as  needed  to  increase  flexibility  in  the  event  of  organizational 
and  network  changes. 

■  Nest  Global  Groups  into  Universal  Groups  to  consolidate  groups  that  span  multiple 
domains. 

■  Place  Global  and  Universal  Groups  into  Domain  Local  Groups  at  the  location  where 
they  will  be  managed. 

■  Assign  permissions  to  the  Domain  Local  Groups. 

A  successful  group  nesting  strategy  aids  security  management  by  administering  security 
policies  consistently  among  groups  and  reduces  errors  that  arise  from  managing  and 
auditing  Active  Directory  object  access  on  a  person-by-person  basis.  When  setting 
Access  Control  Entries  (ACEs)  on  Active  Directory  objects,  it  is  much  easier  to  allow  and 
deny  permissions  to  groups  of  users  than  to  individuals.  Security  management  by  groups 
allows  changes  to  security  permissions  to  be  updated  more  easily  and  accurately. 


Object  Ownership  and  Delegation  of  Control 


Every  object  has  an  owner.  The  owner  controls  how  permissions  are  set  on  an  object, 
and  to  whom  permissions  are  assigned.  If  a  member  of  the  Administrators  group  takes 
ownership,  the  default  owner  is  the  group,  not  the  individual  user.  Whoever  takes 
ownership  is  listed  in  the  Access  Control  Settings  dialog  (from  the  object  Properties 
Security  tab  Advanced  button). 

Object  permissions  for  a  user  or  group  include  permission  to  modify  permissions  and 
ownership.  These  permissions  are  viewed  by  performing  the  following  actions: 

□  Right-click  an  object 

□  Click  Properties 
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□  Click  the  Security  tab 

□  Click  the  Advanced  button 

□  Select  a  permission  entity 

□  Click  the  View/Edit  button 

Allowing  Modify  Permissions  or  Modify  Ownership  permissions  gives  the  user  or  group 
authority  to  gain  Full  Control  over  the  object  (See  Figure  8). 


Warning:  Modify  Permissions 
and  Modify  Owner  both  allow 
a  user  to  gain  Full  Control! 


Figure  8  Modify  Permissions  on  an  Object 

Delegating  Object  Control 

A  preferred  way  to  delegate  administrative  control  over  Active  Directory  objects  is  to 
create  OUs  within  a  domain  and  use  the  Delegation  of  Control  Wizard  to  assign  granular 
permissions  for  administrators.  To  start  the  Delegation  of  Control  Wizard,  right-click  an 
object  in  Active  Directory  Computers  and  Users,  or  select  Delegate  Control  from  the 
Action  pull-down  menu. 


Default  Access  Control  Security  Settings 


During  the  installation  of  Active  Directory,  security  is  enabled  on  the  directory  service  and 
the  file  replication  folders  to  control  access  to  Active  Directory  objects.  Default 
Discretionary  Access  Control  Lists  (DACLs)  are  configured  on  Active  Directory  objects. 
The  default  security  settings  for  Windows  2000  are  held  in  the  following  templates: 


Workstations  -  %systemroot%\inf \def  Itwk  .  inf 
Member  Servers  -  %systemroot%\inf\defltsv.  inf 
Domain  Controllers  -  %systemroot%\inf \def  ltdc  .  inf 
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These  default  templates  can  be  viewed  and  edited  through  the  Security  Templates  snap- 
in  for  the  Microsoft  Management  Console  (MMC).  See  the  Guide  to  Securing  Microsoft 
Windows  2000  Group  Poiicy:  Security  Configuration  Tooiset  mini -guide  for  more 
Information  on  using  security  templates. 


Group  Policy  and  Object  Access  Control 


The  templates  contained  In  the  Security  Configuration  Toolset  can  be  used  to  create 
default  GPOs  for  Active  Directory  Computer  objects.  GPOs  can  be  linked  to  Active 
Directory  Computer  and  User  objects  In  domains,  OUs  and  sites,  as  described  In  the 
Guide  to  Securing  Microsoft  Windows  2000  Group  Po//cy  mlnl-gulde.  When  a  GPO  for  a 
Computer  object  Is  applied  to  a  workstation  or  stand-alone  computer  (through  a  template 
or  through  the  Group  Policy  MMC  snap-ln),  users  who  log  on  to  that  computer  can  Inherit 
the  user  rights  for  the  GPOs  that  apply  to  them.  Templates  and  GPOs  are  generally  the 
best  approach  to  Implementing  a  given  security  policy  for  a  group  or  category  of  users. 


Schema  Access  Control 


The  Schema  defines  the  classes  and  attributes  of  objects  that  can  be  created  In  the 
Active  Directory  database.  The  grouping  of  properties  Is  defined  by  the  property  set 
attribute  of  a  property  In  the  schema. 

When  an  object  Is  created  In  the  directory,  a  default  ACL  Is  applied.  The  default  ACL  Is 
described  In  the  schema  definition  of  the  object  class. 


Moving  Active  Directory  Objects 


Most  Active  Directory  objects  can  be  moved  within  a  domain.  Including  computer 
accounts,  OUs,  and  user  and  group  accounts. 

When  moving  an  Active  Directory  object,  permissions  assigned  to  the  local  object  move 
with  It.  Inherited  permissions  do  not  move  with  the  object,  and  the  object  will  Inherit 
permissions  at  the  destination  container. 

Within  a  domain,  the  Active  Directory  Users  and  Computers  administration  tool  can  be 
used  to  move  objects.  Active  Directory  Users  and  Computers  cannot  move  user 
accounts  between  domains,  however.  To  move  objects  between  domains,  Movetree  or 
one  of  the  other  support  tools  must  be  used  to  copy  objects  from  a  source  domain  to  a 
destination  domain  and  then  delete  the  object  at  the  source  domain. 


ACL  Toois 


Active  Directory  provides  basic  ACL  tools  to  view  and  edit  object  ACLs.  Other  tools  are 
available  from  the  Microsoft  Resource  Kit.  A  list  of  some  of  these  tools  follows. 

Security  Analysis  and  Configuration  is  a  snap-in  that  analyzes  and  configures  local 
machine  system  security.  This  snap-in  can  review  security  analysis  results  and  provide 
recommendations  together  with  current  system  settings.  The  snap-in  can  also  resolve 
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any  discrepancies  reveaied  by  anaiysis,  and  configure  iocai  computer  settings.  It  can 
import  security  tempiates  created  with  the  Security  Tempiates  snap-in,  and  appiy  these  to 
the  GPO  br  the  iocai  computer  to  change  the  iocai  computer  security  settings  to  the 
desired  tempiate.  See  the  Guide  to  Securing  Microsoft  Windows  2000  Group  Poiicy: 
Security  Configuration  Tooiset  mini-guide  for  more  information  on  this  snap-in. 


SECEDIT.EXE  is  the  command-iine  version  of  the  Security  Anaiysis  and  Configuration 
snap-in.  This  program  can  be  caiied  from  a  batch  program  or  automatic  task  scheduier  to 
automaticaiiy  create  and  appiy  tempiates  and  anaiyze  system  security.  See  the  Guide  to 
Securing  Microsoft  Windows  2000  Group  Poiicy:  Security  Configuration  Tooiset  mini¬ 
guide  for  more  information  on  this  tooi. 


DSACLS.EXE  is  a  command-iine  tooi  that  can  query  and  edit  security  attributes.  It  is  the 
command-iine  equivaient  to  the  Security  page  on  various  Active  Directory  snap-in  toois. 


ACLDIAG.EXE  is  a  command-iine  tooi  that  reads  security  attributes  from  an  ACL. 
Output  can  be  formatted  as  readabie  or  tab-deiimited.  ACLDIAG  can  perform  the 
foiiowing: 


■  Compare  the  ACL  on  a  directory  services  object  to  the  permissions  defined  in  the 
schema  defauits 

■  Check  of  fix  standard  deiegations  performed  using  tempiates  from  the  Deiegation  of 
Controi  Wizard  in  Active  Directory  Users  and  Computers 

■  Grant  effective  permissions  to  a  specific  user  or  group  or  to  aii  users  and  groups  that 
are  iisted  in  the  ACL 

ACLDIAG  cannot  read  GPO  permissions  because  a  GPO  is  a  virtuai  object. 


Access  to  Published  Resources 


Windows  2000  aiiows  users  access  to  pubiished  information  and  resources.  This  feature 
is  designed  to  aiiow  the  pubiishing  of  information  and  resources  not  aiready  in  Active 
Directory.  Pubiishing  resources  aiiows  an  administrator  to  pubiish  non-Active  Directory 
resources  with  the  benefit  of  Active  Directory  security  and  access  controi.  This  section 
wiii  briefiy  describe  the  pubiishing  of  printers  and  shared  foiders,  in  particuiar. 


In  Windows  2000,  any  printer  shared  by  a  print  server  that  has  an  account  in  an  Active 
Directory  domain  is  pubiished  in  Active  Directory  by  defauit.  To  remove  printer 
pubiishing,  ciear  the  List  in  the  Directory  check  box  on  the  printer's  Sharing  tab  in  Active 
Directory  Computers  and  Users. 


NOTE:  It  may  help  to  click  User,  Groups,  and  Computers  as 
containers  on  the  View  menu  of  Active  Directory  Computers 
and  Users. 
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Moving  printers  into  asingie  OU  improves  security  management  aiiowing  administration 
to  be  controiied  by  Group  Poiicy.  Aiso,  discretionary  access  controi  iists  (DACLs)  on 
pubiished  resources  can  be  used  to  iimit  access. 

Shared  foiders  can  be  pubiished  using  Active  Directory  Users  and  Computers.  Because  a 
shared  resource  and  a  pubiished  Active  Directory  object  that  refer  to  the  same  shared 
resource  are  separate  entities,  each  has  its  own  DACL.  The  DACL  for  a  shared  printer, 
for  exampie,  controis  who  is  aiiowed  to  print  to  the  printer  and  who  is  aiiowed  to  manage 
print  jobs.  The  DACL  on  the  corresponding  Active  Directory  printQueue  object  controis 
who  can  view  or  change  the  properties  of  the  pubiished  object.  Simiiariy,  the  DACL  for  a 
shared  foider  and  the  DACL  for  an  Active  Directory  Shared  Foider  object  controi  different 
attributes. 


Controlling  Access  to  MMC  Consoles 


Providing  custom  MMC  consoies  to  administrators  couid  be  a  means  to  iimit  the  range  of 
administrative  utiiities  avaiiabie  to  groups  of  administrators.  A  custom  MMC  consoie  is 
created  as  foiiows: 

□  Start  ?  Run  ?  mmc 

□  Add  desired  snap-ins  and  extensions  from  the  Add/Remove  Snap-ins  diaiog 

□  Open  the  Option  diaiog  and  ciick  the  Console  tab 

□  Seiect  User  (or  Author)  mode 

□  Configure  the  aiiowabie  view 

□  Save  the  MMC  consoie 

Author  and  User  modes  determine  how  easiiy  the  target  administrator  can  change  the 
consoie.  Author  mode  freeiy  aiiows  any  changes  to  the  consoie.  In  User  mode  the 
consoie  is  not  changeabie  by  defauit.  Regardiess  of  whether  the  custom  MMC  consoie 
was  saved  in  Author  or  User  mode,  a  user  can  aiways  modify  the  consoie  by  right- 
ciicking  the  consoie,  ciicking  Author,  and  then  changing  the  consoie.  The  oniy  way  to 
prevent  this  is  to  not  assign  NTFS  Write  permission  to  the  .msc  fiie.  Aiso,  the  oniy  way  to 
prevent  a  user  from  creating  their  own  MMC  consoie  and  inciuding  restricted  utiiities  is  to 
remove  the  utiiities  or  deny  fiie  permissions  on  the  target  computer. 


There  are  severai  ways  to  distribute  a  custom  MMC  consoie,  inciuding  the  foiiowing: 


■  Fiie  (through  emaii  or  on  a  removabie  media) 

■  Group  Poiicy 

■  Shared  Foider 

Oniy  the  shared  foider  distribution  method  aiiows  NTFS  fiie  permissions  to  prevent  the 
recipient  from  changing  the  fiie  after  receiving  it. 
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Recommendations 


□  Use  groups  and  group  nesting  to  manage  user  permissions  and  to  manage  and 
audit  access  to  Active  Directory  objects. 

□  Do  not  grant  Modify  Permissions  or  Modify  Ownership  permissions. 

□  Appiy  tempiates  from  the  Security  Configuration  Tooiset  (See  aiso  the  Security 
Configuration  Tooiset  mini-guide). 

□  Estabiish  a  poiicy  to  use  system  security  toois  to  monitor  and  manage  access 
controi  and  security  settings. 

□  Move  printers  into  a  singie  OU  (or  centrai  OUs)  to  simpiify  security  management 
and  to  appiy  a  GPO. 

□  Use  DACLs  on  pubiished  resources  to  manage  access. 

□  Do  not  assign  NTFS  Write  permission  to  a  custom  MMC  consoie  .msc  fiie  if  it  is 
to  remain  unchanged. 

□  Distribute  custom  MMC  consoies  via  shared  foider  with  oniy  Read  &  Execute 
NTFS  permissions  for  users. 


Good  Practices 

□  Avoid  the  use  of  Distribution  Groups. 

□  Track  the  deiegation  of  permission  assignments. 

□  Use  Deny  Permissions  sparingiy. 

□  Deiegate  to  Groups  and  add  specific  users  to  those  groups. 

□  When  changing  or  reviewing  a  DACL  for  a  pubiished  resource,  remember  to 
examine  the  corresponding  DACL  for  the  Active  Directory  object  (and  vice 
versa). 
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Replication 

In  Active  Directory,  each  domain  controiier  keeps  copies  of  a  certain  portion  of  the  Active 
Directory  database.  The  process  of  updating  and  synchronizing  this  information  is 
repiication.  Active  Directory  uses  muiti-master  repiication  with  ioose  convergence.  Muiti- 
master  repiication  aiiows  a  muiti-domain  controiier  network  to  function  if  a  singie  domain 
controiier  becomes  temporariiy  unavaiiabie,  with  a  few  exceptions.  Loose  convergence 
means  that  the  process  of  updating  and  synchronizing  takes  piace  at  various  intervais 
and  scheduies  throughout  a  given  network,  not  aii  at  once  at  a  predictabie  time. 


Replication  Events  and  Conflicts 


Repiication  occurs  when  the  foiiowing  actions  are  performed  on  Active  Directory 
information  stored  on  a  domain  controiier: 

■  Add 

■  Move 

■  Modify 

■  Deiete 

Deiays  or  iatencies  between  repiication  updates  are  based  on  change  notifications 
received  by  a  domain  controiier.  Repiication  iatencies  between  two  domain  controiiers 
within  a  site  occur  based  on  the  foiiowing  scheduies: 

■  5  minutes  -  defauit  repiication  iatency  with  change  notification 

■  One  hour  -  iatency  when  no  changes  occur 

■  Urgent  replication  -  iatency  with  immediate  change  notification 


From  time  to  time,  repiication  updates  on  separate  master  repiicas  is  inconsistent  due  to 
factors  such  as  muitipie  updates  occurring  within  a  iatency  period.  This  inconsistency 
may  iead  to  a  repiication  confiict.  These  confiicts  are  resoived  using  timestamps 
containing  the  version  number,  time,  and  server  ID. 

Replication  conflicts  may  affect  the  addition  or  update  of  object  attributes  that  impact  on 
security.  For  example,  changes  to  group  membership,  ACLs  and  ACEs,  or  Group  Policy 
attributes  may  occasionally  behave  unpredictably. 

As  mentioned  in  the  Group  Policy  section  above,  there  may  be  replication  and 
synchronization  issues  regarding  GPO  updates.  For  example,  if  two  or  more 
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administrators  edit  the  same  GPO  from  different  domain  controiiers,  the  iast  update  wiii 
overwrite  any  previous  updates.  If  an  administrator  makes  more  than  one  change  to  a 
GPO,  the  repiication  of  a  previous  change  couid  overwrite  a  iater  change.  It  is 
recommended  that  administrators  ensure  that  previous  GPO  updates  are  fuiiy  repiicated 
before  proceeding  to  make  additionai  updates. 

Over  time,  Active  Directory  information  automaticaiiy  propagates  from  one  domain 
controiier  to  another,  based  on  iatency  times.  Active  Directory  provides  a  “Repiicate 
Now”  function  to  manuaiiy  initiate  the  repiication  process.  The  “Repiicate  Now”  function 
for  each  server  in  Active  Directory  Sites  and  Services  is  iimited  to  the  server  pair  seiected 
from  the  detaiis  pane.  To  manuaiiy  initiate  repiication  throughout  a  given  domain  from 
any  domain  controiier  in  the  domain,  do  the  foiiowing: 

□  Start  ?  Programs  ?  Administrative  Tools  ?  Active  Directory  Sites  and  Services 

□  Expand  or  doubie-ciick  the  Sites  foider 

□  Expand  or  doubie-ciick  the  Site  Name  icon  (Default-First-Site -Name  uniess  it  has 
been  renamed) 

□  Expand  or  doubie-ciick  the  Servers  foider 

□  Expand  or  doubie-ciick  the  domain-root  server  icon  (i.e.,  the  name  of  the  root 
server) 

□  Seiect  (ieft-ciick)  the  NTDS  Settings  for  the  domain-root  server  icon 

□  In  the  details  pane,  all  of  the  other  servers  should  be  shown 

□  Right-click  a  site  link  connection  in  the  details  pane  and  select  Replicate  Now 
from  the  top  of  the  pop-up  menu 

□  Repeat  the  above  step  for  all  remaining  site  link  connections 

Inter-site  links  can  similarly  be  replicated  from  the  Inter-Site  Transports  folder  of  the 
Active  Directory  Sites  and  Services  interface. 

Universal  Groups  can  be  used  to  consolidate  groups  that  span  multiple  domains. 
However,  membership  changes  to  a  Universal  Group  are  updated  in  the  Global  Catalog 
and  replicated  to  all  global  catalog  servers  in  the  forest.  Further,  any  Universal  Group 
changes  cause  the  entire  membership  list  to  be  replicated.  Global  and  domain  local 
groups  are  listed  in  the  Global  Catalog,  but  their  membership  is  not.  Thus,  changes  to  a 
global  or  domain  local  group  will  not  cause  Global  Catalog  replication  to  occur. 


Site  Replication 


Active  Directory  uses  sites  to  segment  or  partition  normal  replication  within  high-speed 
connections  and  reduce  replication  traffic  across  slow-speed  connections,  namely  WAN 
links.  Sites  are  physically  defined  by  IP  subnets  and  the  specific  parameters  for 
replication  between  them.  Sites  are  also  used  to  control  logon  traffic. 


Within  sites,  replication  occurs  between  domain  controllers  based  on  change  notifications 
and  the  latency  values  for  normal  replication.  The  network  is  assumed  to  be  fast  and 
highly  reliable  and  replication  traffic  is  uncompressed. 
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Between  sites,  replication  occurs  on  a  manually  defined  schedule  to  accommodate 
bandwidth  and  usage  needs  and  schedules.  Replication  traffic  between  sites  is 
compressed.  Active  Directory  automatically  designates  one  or  more  servers  in  each  site 
to  be  a  bridgehead  server  using  a  function  called  the  Intersite  Topology  Generator. 
These  settings  can  be  viewed  and  edited  as  follows: 

□  From  Active  Directory  Sites  and  Services,  expand  and  select  a  site  in  the  Sites 
folder 

□  In  the  details  pane,  right-click  the  NTDS  Site  Settings  object  and  click  Properties 

The  Active  Directory  Sites  and  Services  tool  can  be  used  to  schedule  site  links  for  times 
when  network  traffic  is  relatively  low. 


Site  Replication  Protocols 

Replication  within  sites  must  use  the  Remote  Procedure  Call  (RPC)  protocol  over  IP. 
Replication  between  sites  can  be  either  RPC  or  Simple  Mail  Transfer  Protocol  (SMTP). 

For  systems  that  cross  firewall  boundaries,  the  choice  of  RPC  or  SMTP  may  be 
significant.  The  RPC  protocol  has  associated  with  it  numerous  security  concerns  and  is 
often  blocked  at  filtering  routers.  A  system  security  policy  that  prohibits  RPC  across 
routers  would  necessitate  the  use  of  SMTP  for  replication  between  sites. 

Placement  of  Senders  Within  Sites 

Sites  have  some  special  requirements  that  affect  server  placement.  The  following  are 
some  general  recommendations: 

□  Each  site  should  have  at  least  one  domain  controller 

□  Global  Catalog  Servers  must  be  available  for  user  log  on  in  a  native -mode 
domain,  or  when  a  user  logs  on  with  a  user  principal  name 

□  DNS  servers  are  needed  so  that  clients  can  find  domain  controllers  and  domain 
controllers  can  find  other  domain  controllers 


If  there  is  no  domain  controller  within  a  given  site,  then  DNS,  not  Active  Directory, 
determines  where  to  search  for  a  network  resource.  In  a  large  system,  this  type  of 
search  may  be  relatively  inefficient,  depending  on  the  DNS  configurations  of  the  clients 
and  servers. 


Replication  Monitor 


Active  Directory  provides  a  Replication  Monitor  tool  (replmon.exe)  to  graphically 
display  the  replication  topology  of  connections  between  servers  in  the  same  site. 
Replication  Monitor  can  perform  the  following: 


■  Display  the  replicating  partner 

■  Display  each  USN  value,  the  number  of  failed  attempts,  reason,  and  flags 
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■  Poll  the  server  at  an  administrator-defined  Interval 

■  Monitor  the  count  of  failed  replication  attempts 

■  Show  which  objects  have  not  yet  been  replicated 

■  Synchronize  between  just  two  domain  controllers 

■  Trigger  the  KCC  Into  recalculating  the  replication  topology 
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Recommendations 

□  Manually  Initiate  NTDS  replication  to  Increase  the  certainty  that  security  settings 
begin  replication  In  a  timely  manner. 

□  If  lack  of  network  bandwidth  Is  a  security  concern,  minimize  membership  In  and 
use  of  Universal  Groups  to  reduce  replication  overhead.  If  lack  of  network 
bandwidth  Is  a  security  concern. 

□  Use  SMTP  for  replication  between  sites  where  replication  crosses  a  firewall 
boundary. 


Good  Practices 

□  Periodically  review  security  configurations  and  settings  for  accuracy,  especially 
following  multiple  and/or  significant  changes  to  Active  Directory;  replication 
latency  could  be  minute,  hours,  or  days  depending  on  system  conditions. 

□  Use  the  Replication  Monitor  tool  to  monitor  the  replication  structure  and 
periodically  recalculate  replication  topology. 
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Operations  Masters 

Active  Directory  is  designed  to  perform  muiti-master  operation  and  repiication,  with 
confiict  resoiution.  Some  operations  make  use  of  singie  master  or  operations  master 
roies  primariiy  for  backward-compatibiiity  and  for  appiications  that  are  intoierant  of 
coiiisions.  This  chapter  discusses  the  security  concerns  and  recommendations  for 
operations  masters. 


Operations  Master  Roles 


The  five  operations  master  roies  are: 

■  Schema  master 

■  the  oniy  domain  controiier  that  can  write  to  the  directory  schema 

■  Domain  naming  master 

■  the  oniy  domain  controiier  that  can  add  or  remove  domains 

■  PDC  Emuiator 

■  acts  as  the  PDC  for  any  existing  BDCs 

■  manages  password  changes  from  computers  running  Windows  95/98/NT 

■  minimizes  repiication  iatency  for  password  changes 

■  synchronizes  the  time  on  aii  domain  controiiers  throughout  the  domain  to  its  time 

■  prevents  the  possibiiity  of  overwriting  GPOs 

■  RID  master 

■  aiiocates  blocks  of  relative  identifiers  to  each  domain  controller  in  its  domain 

■  prevents  object  duplication  if  objects  move  from  one  domain  controller  to  another 

■  Infrastructure  master 

■  updates  references  to  objects  and  group  memberships  from  other  domains 

■  not  needed  in  a  single  domain  forest 
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There  is  only  one  schema  master  and  domain  naming  master  per  forest.  The  other 
operations  masters  are  per-domain;  i.e.,  there  is  only  one  PDC  Emulator,  RID  master  and 
Infrastructure  master  per  domain. 


Operations  Masters  Placement 


Because  the  domain-naming  master  verifies  the  name  of  a  new  object  by  querying  the 
global  catalog  server,  the  global  catalog  must  run  on  the  same  domain  controller  as  the 
one  holding  the  domain  naming  master  role.  The  global  catalog  runs  on  the  forest  root 
domain  controller,  by  default. 

The  infrastructure  operations  master  should  not  be  the  same  domain  controller  that  hosts 
the  global  catalog.  If  the  infrastructure  master  and  the  global  catalog  are  the  same 
computer,  the  infrastructure  master  will  not  function  because  it  does  not  contain  any 
references  to  objects  that  it  does  not  hold. 

It  is  good  practice  to  place  the  schema  and  domain-naming  masters  at  the  global  catalog 
domain  controller.  The  other  three  roles  should  be  distributed  to  separate  servers,  to  the 
extent  possible,  to  increase  fault  tolerance.  There  should  be  at  least  one  replica  in  the 
forest  root  domain,  for  fault  tolerance. 

Operations  master  roles  can  be  transferred  from  one  domain  controller  to  another,  when 
operationally  necessary.  If  an  operations  master  role  server  becomes  disabled  for  an 
extended  period,  its  role  must  be  seized.  These  transfer  and  seize  operations  can  be 
performed  from  any  available  domain  controller  within  the  affected  domain,  or  to  which  a 
connection  is  made. 


Global  Catalog  Server 


The  Global  Catalog  holds  a  copy  (replica)  of  every  object  in  Active  Directory,  but  with  a 
limited  number  of  each  object’s  attributes.  The  Global  Catalog  stores  those  attributes 
most  frequently  used  in  search  operations,  and  attributes  required  to  locate  a  full  replica 
of  the  object. 

The  first  domain  controller  in  a  forest  is  automatically  designated  as  the  global  catalog 
server.  An  administrator  can  view  and  manage  the  global  catalog  server  designation 
through  the  Active  Directory  Sites  and  Services  tool  as  follows: 

□  In  Active  Directory  Sites  and  Services,  expand  the  console  tree  and  navigate  to 
the  domain  controller  NTDS  settings 

□  Right-click  the  domain  controller  NTDS  settings 

□  Click  Properties 

The  Global  Catalog  check  box  on  the  General  tab  can  be  used  to  make  a  domain 
controller  a  global  catalog  server  or  to  demote  a  global  catalog  server.  It  is 
recommended  that  there  be  one  global  catalog  server  per  site.  More  than  one  global 
catalog  server  per  site  is  generally  not  needed.  A  global  catalog  server  should  not  be 
demoted  unless  another  domain  controller  is  hosting  the  global  catalog  server  role. 
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Global  catalog  servers  must  be  available  to  support  authentication  requests,  locate 
system  resources,  and  enable  Active  Directory  functionality  such  as  universal  groups. 
For  example,  without  access  to  a  global  catalog  server,  the  Local  Security  Authority 
(LSA)  on  the  user’s  computer  cannot  Include  the  user’s  universal  groups  In  his  or  her 
security  token.  Since  such  groups  might  be  used  to  deny  access  to  certain  resources. 
Active  Directory  will  refuse  a  logon  request  In  a  native-mode  domain  If  a  global  catalog 
server  Is  unavailable. 

The  domain  controller  servicing  an  authentication  request  must  be  able  to  communicate 
with  a  global  catalog  server.  The  Global  Catalog  query  Is  sent  to  port  3268  on  the 
domain  controller.  Standard  Active  Directory  queries,  which  are  directed  to  the  domain- 
local  partition,  are  sent  to  port  389,  which  Is  the  standard  LDAP  port.  Because  these 
ports  are  well  known  and  are  critical  to  the  functioning  of  Active  Directory,  they  are 
susceptible  to  various  forms  of  denial  of  service  attacks,  such  as  IP  packet  flooding.  It  Is 
not  realistic  that  these  ports  can  be  shielded  from  a  denial  of  service  attack  from  Inside  a 
given  system.  Measures  should  be  taken  to  protect  and  hide  the  Identity  of  domain 
controllers  serving  requests  to  these  (and  other)  ports  from  outside  the  enterprise 
security  perimeter. 
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Recommendations 

□  Permanently  remove  from  the  network  a  disabled  domain  controller  that  held  a 
schema  master,  domain-naming  master,  or  RID  master  whose  role  has  been 
seized. 

□  Take  measures  to  hide  the  Identity  of  domain  controllers  from  external  networks. 


Good  Practices 

□  Transfer  operations  master  roles  before  demoting  a  domain  controller. 

□  Consider  the  network  traffic  for  GPO  refresh,  password  changes,  and  time 
synchronization  when  assigning  the  PDC  Emulator  to  a  domain  controller. 

□  Assign  the  schema  and  domain  naming  master  roles  to  the  domain  controller  that 
runs  the  global  catalog. 

□  Place  a  global  catalog  server  In  the  same  site  as  the  Infrastructure  master. 

□  Consider  network  traffic  and  accessibility  when  determining  the  location  of  the 
global  catalog  server. 
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Auditing 

An  audit  strategy  is  provided  with  the  Guide  to  Securing  Microsoft  Windows  2000  Group 
Poiicy:  Security  Configuration  Tooiset  mini-guide.  It  is  recommended  that  administrators 
begin  with  the  Tooiset  tempiate  as  a  baseiine  audit  poiicy.  This  section  of  the  Active 
Directory  mini-guide  provides  a  simpie  overview  of  Active  Directory  audit  capabiiities. 


Enabling  Auditing  on  AD  Objects 


Enabiing  audit  settings  adds  Access  Controi  Entries  (ACEs)  to  the  System  Access 
Controi  List  (SACL)  of  the  security  descriptor  of  the  Active  Directory  object  to  be  audited. 

To  configure  an  audit  poiicy  for  a  domain  controiier,  do  the  foiiowing: 

□  Start  ?  Run  ?  mmc 

□  From  the  Console  puii-down  menu  seiect  Add/Remove  Snap-in 

□  Ciick  the  Add  button 

□  Doubie-ciick  the  Group  Policy  snap-in 

□  From  the  Select  Group  Policy  Objectdiaiog,  ciick  the  Browse  button 

□  Ciick  the  All  tab  to  view  aii  GPOs  for  the  domain 

□  Seiect  the  domain  controiiers  poiicy  and  ciick  OK 

□  Ciick  the  Finish  button 

□  Ciick  the  Close  button 

□  From  the  Add/Remove  Snap-in  diaiog,  ciick  the  OK  button  to  add  the  domain 
controiiers  Group  Poiicy  snap-in 

□  From  the  domain  controiiers  group  poiicy  consoie  tree,  expand  and  navigate  to 
Computer  Configuration?  Windows  Settings?  Security  Settings?  Local 
Policies?  Audit  Policy 

□  Doubie-ciick  each  poiicy  in  the  detaiis  pane  to  view  or  edit  the  poiicy 

The  procedure  to  enabie  audit  settings  for  other  GPOs  is  the  same,  except  that  a 
different  GPO  is  seiected  as  the  object  of  the  MMC  snap-in.  The  way  to  enabie  audit  for 
an  OU,  for  exampie,  is  to  iink  a  GPO  to  the  OU  and  configure  audit  settings  for  the  GPO. 

Audit  can  be  enabied  for  individuai  computer,  user,  and  group  Active  Directory  objects. 
To  set  an  auditing  SACL  on  an  individuai  object,  do  the  foiiowing: 
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Start  ?  Programs  ?  Administrative  Tools  ?  Active  Directory  Users  and 
Computers 

On  the  View  menu,  select  Advanced  Features 

Expand  the  console  tree  and  navigate  to  the  container  holding  the  target  object 
Right-click  the  target  object  from  the  details  pane  and  select  Properties 
Click  the  Security  tab 
Click  the  Advanced  button 
Select  the  Auditing  tab 

Click  the  Add  button  to  see  the  Select  User,  Computer,  or  Group  dialog 
Select  a  security  principal  name  and  click  OK 

The  Auditing  Entry  for  <object>  dialog  appears  with  two  tabs:  Object  and 
Properties 

NOTE:  The  Object  tab  contains  generic  and  control  rights  to 

-  audit.  The  Property  tab  contains  property  accesses  to  audit. 

I  The  “Apply  onto:”  pull-down  menu  provides  the  choice  “This 
]  object  and  all  child  objects”  by  default,  or  various  other 
r  object  scopes.  The  “Apply  these  auditing  entries  to  objects 
and/or  containers  within  this  container  only”  checkbox 
applies  audit  within  the  current  container  if  checked,  or 
throughout  the  domain  if  unchecked 

Select  Object  and/or  Property  accesses  and  click  OK 


At  the  Access  Control  Settings  window,  determine  whether  auditing  entries  must 
be  Inherited  from  the  parent  container  to  propagate  this  object.  If  so,  check  the 
Allow  inheritable  auditing  entries  from  parent  to  propagate  to  this  object  checkbox. 


At  the  Properties  window,  determine  whether  auditing  permissions  must  be 
Inherited  from  the  parent  container  to  this  object.  If  so,  check  the  Allow 
inheritable  auditing  entries  from  parent  to  propagate  to  this  object  checkbox. 


Audit  settings  are  set  as  “Local  Policies.”  Local  policies  are  local  to  a  computer,  with  no 
distinction  among  the  types  of  computers,  such  as  domain  controllers,  servers,  or 
workstations. 


Reviewing  Audit  events 


Audit  events  are  recorded  In  the  computer's  Security  Log  In  the  Event  Viewer.  To  view 
the  audit  log,  do  the  following: 

□  Start  ?  Programs  ?  Administrative  Tools  ?  Event  Viewer 

□  Select  Security  Log  from  the  Event  Viewer  console  tree 

To  view  and  edit  the  file  system  properties  of  the  audit  log,  right-click  on  the  Security  Log 
to  open  the  Security  Log  Properties  dialog.  From  this  dialog,  the  log  size  and  overwrite 
options  can  be  configured  from  the  General  tab.  Filtering  options  are  available  from  the 
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Filter  tab.  It  is  recommended  that  the  settings  from  the  Security  Configuration  Tooiset 
tempiate  and  mini -guide  be  used  as  a  baseiine  poiicy  for  the  security  iog  properties. 

The  iogging  of  audit  events  can  generate  voiuminous  output.  An  audit  poiicy  shouid  be 
impiemented  to  manage  review  and  anaiysis,  and  fiie  system  issues.  Audit  settings 
shouid  be  tested  to  see  if: 


■  They  capture  the  expected  events 

■  Audit  iog  data  can  be  anaiyzed  and  understood 

■  The  amount  of  audit  iog  data  is  manageabie 

For  events  where  data  is  returned  to  the  event  properties  data  text  area,  the  returned 
data  code  can  be  transiated  using  the  net  heipmsg  command  iine  utiiity.  To  use  the 
net  heipmsg  utiiity,  from  the  Data  text  area,  transiate  the  hexadecimai  code  to  decimai 
by  ciicking  the  Words  radio  button.  Then  run  net  heipmsg  <message  decimal 
number>  to  get  a  description. 

In  addition  to  the  Event  Viewer,  numerous  iog  fiies  exist  in  various  piaces  in  the  Windows 
2000  fiie  system.  The  debug  iog  fiies  iocated  in  the  %Systemroot%\Debug  foider  often 
contain  events  that  may  be  reiated  to  security.  The  debug  iog  fiies  are  as  foiiows: 


■  DCPromoUl.log  -  detaiied  progress  report  of  the  Active  directory  instaiiation  and 
removai  processes 

■  DCPromos.log  -  created  by  the  user  interface  during  the  graphicai  user  interface 
mode  setup  when  a  Windows  NT  4.0  domain  controiier  is  promoted  to  a  Windows 
2000  domain  controiier 

■  DCPromo.log  -  created  by  using  the  Active  Directory  Instaiiation  Wizard 

■  Netsetup.log  -  provides  information  about  the  attempts  to  join  domains  and  records 
any  errors  that  might  resuit 

■  Netlogon.log  -  created  whenever  the  Net  Logon  service  is  used 

■  Ntfrsapi.log  -  contains  events  that  take  piace  during  the  instaiiation  or  removai  of 
Active  Directory  regarding  the  Fiie  Repiication  Service 

■  Userenv.log  -  can  be  usefui  in  troubieshooting  probiems  with  user  profiies  and 
Group  Poiicy  processing 
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Recommendations 

□  Refer  to  the  Security  Configuration  Tooiset  tempiate  and  mini-guide  as  a 
baseiine  generai  audit  poiicy 

□  Identify  and  audit  specific  user,  computer,  group  and  other  objects  that  have 
security  significance 

□  Formuiate  a  test  pian  to  test  major  changes  to  audit  settings 
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Good  Practices 

□  Monitor  other  security-related  Windows  2000  logs,  such  as  the  debug  logs 
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Backup/Restore  and  Database  Maintenance 

Active  Directory  backup  and  restore  are  essentiai  components  of  a  contingency  pianning 
and  disaster  recovery  security  poiicy.  As  far  as  the  Active  Directory  database  is 
concerned,  the  system  state  data  is  the  most  important  data  to  be  backed  up.  See  the 
Guide  to  Securing  Microsoft  Windows  2000  Fiie  Resources  mini-guide  for  more 
information  on  system  backups. 


Backup 


To  back  up  the  system  state  data,  do  the  foiiowing: 

□  Start  ?  Programs?  Accessories?  System  Tools?  Backup 

□  Ciick  the  Backup  Wizard  button 

□  From  the  Backup  Wizard  diaiog,  ciick  Next 

□  Ciick  the  Only  back  up  the  System  State  data  radio  button 

□  Ciick  the  Browse  button  to  seiect  the  backup  media  destination 

□  Ciick  Next 

□  Review  the  settings  and  ciick  Finish 

Because  Backup  supports  oniy  iocai  backups  of  Active  Directory,  each  domain  controiier 
must  be  backed  up  to  entireiy  back  up  Active  Directory.  For  fuii  disaster  recovery,  seiect 
“Back  up  everything  on  my  computer”  from  the  “What  to  Back  Up”  menu. 


Restore 


Active  Directory  restore  can  be  non-authoritative  or  authoritative.  A  non-authoritative 
restore  reinstates  the  Active  Directory  data  to  its  state  before  the  iast  backup.  Distributed 
services  are  restored  from  the  backup  and  the  restored  data  is  then  updated  through 
repiication.  Because  the  restore  is  non-authoritative,  aii  changes  since  the  iast  backup 
wiii  overwrite  restored  data  upon  repiication.  To  perform  a  non-authoritative  restore: 


□  Restart  the  domain  controiier,  and  press  the  F8  key  to  dispiay  the  advanced 
startup  options 

□  Seiect  Directory  Services  Restore  Mode  to  start  Windows  2000  (this  option  does 
not  start  Active  Directory  and  does  not  enabie  network  connections) 
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□  Logon  using  the  local  Administrator  account 

□  Use  Backup  to  restore  the  latest  system  data 

□  Restart  the  domain  controller 

An  authoritative  restore  allows  the  administrator  to  mark  data  as  current,  thus  preventing 
replication  from  overwriting  that  information.  An  authoritative  restore  occurs  after  a  non- 
authoritative  restore,  typically  to  restore  Active  Directory  to  a  previously  known  safe  state; 
for  example,  before  Active  Directory  objects  were  accidentally  deleted.  To  perform  an 
authoritative  restore: 

□  Restart  the  domain  controller,  and  press  the  F8  key  to  display  the  advanced 
startup  options 

□  Select  Directory  Services  Restore  Mode  to  start  Windows  2000  (this  option  does 
not  start  Active  Directory  and  does  not  enable  network  connections) 

□  Logon  using  the  local  Administrator  account 

□  Use  Backup  to  restore  Active  Directory  to  its  original  location.  Also,  restore 
Active  Directory  to  an  alternate  location  when  you  need  to  perform  an 
authoritative  restore  on  the  SYSVOL. 

□  At  a  command  prompt,  type  ntdsutil 

□  At  the  ntdsutil  prompt,  type  authoritative  restore 

□  At  the  authoritative  restore  prompt,  type  restore  subreee 
<distinguished  name  of  object> 

□  Type  quit  and  press  enter  twice  to  exit  ntdsutil 

□  Restart  the  domain  controller 

To  perform  an  authoritative  restore,  the  administrator  must  know  the  distinguished  names 
of  objects  to  be  restored.  Therefore,  it  is  recommended  that  system  administrators  keep 
an  updated  object  map  from  which  to  restore  Active  Directory  objects. 

When  objects  are  deleted,  they  are  marked  as  “tombstone”  objects.  Garbage  collection 
runs  on  every  domain  controller  after  every  12  hours  of  operation.  The  default  tombstone 
lifetime  (set  in  the  registry)  is  60  days.  The  backup  of  the  system  state  data  cannot  be 
older  than  the  tombstone  lifetime.  A  domain  controller  keeps  track  of  deleted  objects  for 
only  this  period.  Tombstones  cannot  be  restored. 

Backup  erases  the  system  state  data  upon  restore  and  replaces  it  with  the  system  state 
data  being  restored.  Depending  on  how  old  the  system  state  data  is,  recent  configuration 
changes  could  be  lost.  System  state  data  should  be  backed  up  frequently  to  reduce  risk 
of  losing  state  data. 

Schema  changes  are  permanent.  A  Schema  Admin  cannot  mark  the  schema  directory 
partition  as  authoritative;  therefore,  schema  changes  cannot  be  undone  using  an 
authoritative  restore.  It  is  recommended  that  a  backup  be  performed  before  making 
schema  changes. 
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Recommendations 


□  Ensure  a  robust  password  policy,  as  described  in  the  Guide  to  Securing 
Microsoft  Windows  2000  Group  Poiicy:  Security  Configuration  Tooiset  mini¬ 
guide,  is  enforced  for  local  Administrator  passwords  used  to  protect  the 
ntds  .dit  Active  Directory  database  file  while  in  restore  mode 

□  Maintain  an  up-to-date  Active  Directory  object  map  from  which  to  perform 
authoritative  restore,  in  case  something  important  is  accidentally  deleted 

□  The  tombstone  lifetime  interval  should  not  be  greatly  reduced 

□  Separate  the  database  and  backup  files 

□  Back  up  the  system  state  data  of  domain  controllers  frequently 

□  Do  a  backup  before  making  changes  to  the  schema 
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